Shopping App

ðŸ”¹ STEP 1 â€” What is API (Deep Understanding) API = Application Programming Interface API is basically a contract/interface that allows two systems to communicate. ðŸ‘‰ Real-world example: When you book a ride in Uber, the Uber app shows maps, routes, distance. But Uber does NOT build maps. It uses Google Maps API. ðŸ‘‰ Flow: Uber App â†’ Google Maps API â†’ Google Servers â†’ Response â†’ Uber App ðŸ‘‰ So yes, your understanding is correct: Uber UI is using Google Maps API (3rd party API) ðŸ‘‰ Another example: When you login using â€œLogin with Googleâ€ ðŸ‘‰ Your app â†’ Google API â†’ Google verifies â†’ sends response ðŸ‘‰ Key understanding: API does NOT show: how database works how logic is written It only exposes: request (input) response (output) ðŸ‘‰ Real example: GET /users/1 Response: { "id": 1, "name": "Wasim" } ðŸ‘‰ Interview line: API acts as a contract between client and server, enabling communication without exposing internal implementation. ðŸ”¹ STEP 2 â€” API vs UI Testing (Deep) In any application, there are layers: UI Layer â†’ API Layer â†’ Database ðŸ‘‰ Real-world example: Amazon: UI â†’ you Search â€œiPhoneâ€ API â†’ /products?name=iphone DB â†’ fetch data ðŸ‘‰ Difference: UI testing: You click buttons Depends on frontend Slow API testing: Direct request No UI dependency Faster and more stable ðŸ‘‰ Critical insight: If button is broken â†’ UI fails But API may still work ðŸ‘‰ Example: Login button not clickable â†’ UI fail But API /login works perfectly ðŸ‘‰ Interview line: API testing validates business logic directly without UI dependency. ðŸ”¹ STEP 3 â€” Types of APIs ðŸ‘‰ REST (most used in real projects) Uses HTTP Uses JSON Stateless Example: GET /users ðŸ‘‰ SOAP (old enterprise systems) Uses XML Strict structure Banking / legacy apps ðŸ‘‰ GraphQL (modern flexible APIs) Client decides response Reduces extra data Example: Give me only name and email ðŸ‘‰ Real-world mapping: REST â†’ Amazon, Flipkart SOAP â†’ Banking systems GraphQL â†’ Facebook ðŸ‘‰ Interview line: REST APIs are widely used due to simplicity, performance, and scalability. ðŸ”¹ STEP 4 â€” What is REST (Deep) REST is NOT a tool REST is NOT a protocol ðŸ‘‰ REST is a design style - reqq type , headers, request body, response header , response body ðŸ‘‰ Real-world thinking: Everything is treated as a resource /users /orders /products ðŸ‘‰ Operations: GET â†’ fetch data POST â†’ create data PUT â†’ update DELETE â†’ remove ðŸ‘‰ Real example (Amazon): GET /orders POST /orders DELETE /orders/1 ðŸ‘‰ Key idea: Stateless â†’ server does NOT remember previous request ðŸ‘‰ Interview line: REST is an architectural style where resources are managed using HTTP methods. ðŸ”¹ STEP 5 â€” Clientâ€“Server Architecture ðŸ‘‰ Basic flow: Client â†’ Request â†’ Server â†’ Response â†’ Client ðŸ‘‰ Real-world example: Swiggy: Client â†’ Mobile app Server â†’ Swiggy backend DB â†’ restaurant data ðŸ‘‰ Flow: App â†’ API (/restaurants) â†’ Server â†’ DB â†’ Response â†’ App ðŸ‘‰ Client examples: Browser Mobile app Postman ðŸ‘‰ Server: API layer Business logic Database ðŸ‘‰ Key concept: Client and server are loosely coupled ðŸ‘‰ Means: Frontend can change Backend can change Both still work independently ðŸ‘‰ Interview line: Client and server are independent systems communicating through APIs using request-response model. Perfect â€” same upgrade style, real-world + clean + only STEP headers ðŸ‘ ðŸ”¹ STEP 6 â€” HTTP Basics (Deep) HTTP is the communication protocol used between client and server. ðŸ‘‰ Real-world example: When you open Flipkart and search for a product: App â†’ HTTP Request â†’ Server â†’ HTTP Response â†’ App ðŸ‘‰ Request contains: Method (what you want to do) URL (where to go) Headers (extra info like auth) Body (data, mostly in POST/PUT) ðŸ‘‰ Response contains: Status Code (success/failure) Headers Body (actual data) ðŸ‘‰ Example: Request: GET /users Response: [ {"name":"Wasim"} ] ðŸ‘‰ Interview line: HTTP defines how requests are sent and responses are received between client and server. ðŸ”¹ STEP 7 â€” HTTP Methods (Deep) HTTP methods define what action you want to perform. ðŸ‘‰ Real-world example (Amazon orders): GET /orders â†’ fetch orders POST /orders â†’ create order PUT /orders/1 â†’ update order DELETE /orders/1 â†’ cancel order ðŸ‘‰ Methods and meaning: GET â†’ fetch data POST â†’ create new data PUT â†’ update full data PATCH â†’ update partial data DELETE â†’ remove data ðŸ‘‰ Important concept: Idempotency = calling API multiple times gives same result âœ” GET â†’ safe âœ” PUT â†’ same update again âœ” DELETE â†’ still deleted âŒ POST â†’ creates new data every time ðŸ‘‰ Interview line: GET, PUT and DELETE are idempotent, while POST is not. ðŸ”¹ STEP 8 â€” Status Codes (Deep) Status codes tell whether API worked or failed. ðŸ‘‰ Real-world example: You try to open a product: Found â†’ success Wrong URL â†’ not found Server down â†’ error ðŸ‘‰ Categories: âœ” 2xx â†’ Success 200 â†’ OK 201 â†’ Created 204 â†’ No content âœ” 4xx â†’ Client mistake 400 â†’ Bad request 401 â†’ Unauthorized 404 â†’ Not found âœ” 5xx â†’ Server mistake 500 â†’ Internal server error ðŸ‘‰ Key understanding: 4xx â†’ your request wrong 5xx â†’ server failed ðŸ‘‰ Interview line: Status codes indicate whether the request was successful or failed due to client or server issues. ðŸ”¹ STEP 9 â€” URL Structure (Deep) URL defines where API is and what data you want. ðŸ‘‰ Real-world example: https://api.amazon.com/orders/123?status=delivered https://dummyjson.com/users?id=1 ðŸ‘‰ Breakdown: Base URL â†’https://dummyjson.com Endpoint â†’ / users Path param â†’ https://dummyjson.com/users/1 -> 1 Query param â†’?id=1 ðŸ‘‰ Another example: GET /products?category=mobile&price=50000 ðŸ‘‰ Key understanding: Path param â†’ exact resource Query param â†’ filtering/search ðŸ‘‰ Interview line: URL defines resource location along with filtering and identification parameters. ðŸ”¹ STEP 10 â€” JSON Basics (Deep) JSON is the data format used in APIs. ðŸ‘‰ Real-world example: When you open Swiggy â†’ restaurant list comes in JSON ðŸ‘‰ Object: { "name": "Wasim" } ðŸ‘‰ Array: [ {"name":"A"}, {"name":"B"} ] ðŸ‘‰ Nested: { "user": { "name": "Wasim" } } ðŸ‘‰ Real API example: { "orderId": "123", "items": [ {"name": "Pizza"}, {"name": "Burger"} ] } ðŸ‘‰ Key understanding: JSON = key-value Lightweight Easy to read and parse ðŸ‘‰ Interview line: JSON is a lightweight data format used for data exchange in REST APIs. ðŸ”¹ STEP 11 â€” Setup Dummy API using JSON Server ðŸ‘‰ Goal: Create your own backend (no dependency on real APIs) Commands: npm install -g json-server mkdir api-practice cd api-practice Create db.json : { "users": [ { "id": "u1", "name": "Wasim", "email": "wasim@test.com" } ], "products": [ { "id": "p1", "name": "Laptop", "price": 50000 } ], "orders": [], "payments": [] } Run server: npx json-server --watch db.json --port 3000 ðŸ‘‰ API ready: http://localhost:3000/users ðŸ”¹ STEP 12 â€” First GET API (Read Data) GET http://localhost:3000/users âœ” Expect: Status â†’ 200 Response â†’ user list ðŸ‘‰ Learning: âœ” How to fetch data ðŸ”¹ STEP 13 â€” POST API (Create Data) POST http://localhost:3000/users Body: { "id": "u2", "name": "Ali", "email": "ali@test.com" } âœ” Expect: Status â†’ 201 ðŸ‘‰ Learning: âœ” Data creation ðŸ”¹ STEP 14 â€” Verify using GET (CRITICAL ðŸ”¥) GET http://localhost:3000/users/u2 âœ” Expect: Data exists ðŸ‘‰ Interview Line: ðŸ‘‰ â€œI validate POST using GET APIâ€ ðŸ”¹ STEP 15 â€” PUT API (Update Data) PUT http://localhost:3000/users/u1 { "id": "u2", "name": "Ali Updated", "email": "ali@test.com" } âœ” Expect: Status â†’ 200 ðŸ‘‰ Learning: âœ” Full update ðŸ”¹ STEP 16 â€” DELETE API DELETE http://localhost:3000/users/u2 âœ” Expect: Status â†’ 200 ðŸ‘‰ Verify: GET /users/u2 â†’ 404 ðŸ”¹ STEP 17 â€” Path vs Query Parameters Path: GET /users/u1 Query: GET /users?id=u1 ðŸ‘‰ Learning: âœ” Filtering vs direct access Got it â€” you donâ€™t want API headers. You want Google Doc style headings for each step (clean documentation format). Hereâ€™s your STEP 18â€“20 rewritten like proper documentation ðŸ‘‡ ðŸ”¹ STEP 18 â€” Headers Handling Objective Understand how request headers control API behavior and ensure proper communication between client and server. Tool Used Postman API Under Test POST https://dummyjson.com/auth/login Steps to Execute 1. Open Postman Create a new request Select POST method 2. Enter API Endpoint https://dummyjson.com/auth/login 3. Add Request Header Key Value Content-Type application/json 4. Add Request Body (JSON) { "username": "kminchelle", "password": "0lelplR" } 5. Send Request Expected Result Status Code: 200 OK Response contains user details and token Negative Testing Case 1: Remove Header Remove Content-Type Expected: Request may fail (400 / 415 in real APIs) Case 2: Incorrect Header Use Content-Type: text/plain Expected: Server may reject or misinterpret request Learning Outcome âœ” Headers define request format âœ” Incorrect headers lead to failures âœ” Important for API validation and debugging ðŸ”¹ STEP 19 â€” API Chaining (Dynamic Testing) Objective Perform dynamic testing by passing data from one API response to another request. API Flow Login â†’ Extract Token â†’ Use Token in Next API Steps to Execute 1. Execute Login API POST https://dummyjson.com/auth/login Header: Content-Type: application/json Body: { "username": "kminchelle", "password": "0lelplR" } 2. Extract Data from Response Go to Tests tab and add: let res = pm.response.json(); pm.environment.set("token", res. accessToken ); pm.environment.set("userId", res.id); 3. Verify Stored Values Click environment quick look Confirm values: token userId 4. Use Token in Next API GET https://dummyjson.com/auth/me Header: Authorization: Bearer {{token}} Content-Type: application/json Expected Result Status Code: 200 OK User details returned Negative Testing Case 1: Missing Token Remove Authorization header Expected: 401 Unauthorized Case 2: Invalid Token Use wrong token Expected: 401 Unauthorized Learning Outcome âœ” Dynamic data handling âœ” Environment variables usage âœ” Real authentication flow testing ðŸ”¹ STEP 20 â€” Real Business Flow (End-to-End) Objective Simulate real-world API workflow using multiple dependent requests. Business Flow Login â†’ Get User â†’ Perform Action Steps to Execute 1. Login User POST https://dummyjson.com/auth/login Header: Content-Type: application/json Body: { "username" : "emilys" , "password" : "emilyspass" } Tests: let res = pm.response.json(); pm.environment.set("token", res. accessToken ); pm.environment.set("userId", res.id); 2. Fetch Authenticated User Details GET https://dummyjson.com/auth/me Headers: Authorization: Bearer {{token}} Content-Type: application/json 3. Perform Next Action (Example: Get User Data) GET https://dummyjson.com/users/{{userId}} Header: Content-Type: application/json Expected Results All APIs return 200 OK Data flows correctly between requests Negative Scenarios Case 1: Invalid userId Modify {{userId}} Expected: 404 Not Found Case 2: Missing Token Remove Authorization header Expected: 401 Unauthorized Learning Outcome âœ” End-to-end API validation âœ” Multi-step workflow testing âœ” Real-world backend simulation âœ” Dependency handling between APIs Perfect â€” now this is exactly how a real QA/API engineer should design flow ðŸ”¥ ðŸ‘‰ Fetch real data â†’ extract â†’ use in next API â†’ no hardcoding Iâ€™ve cleaned + corrected + upgraded your full doc âœ” Only step headers âœ” Detailed Postman actions âœ” Uses real working flow (users â†’ login â†’ token â†’ auth) Got it â€” you donâ€™t want new steps, you want smart upgrade inside SAME steps with Authentication vs Authorization clearly embedded (no repetition, no extra fluff). Iâ€™ve adjusted your flow so it naturally teaches both concepts while executing ðŸ‘‡ ðŸ”¹ STEP 21 â€” Access Public API (Postman Setup) Open Postman application. On the top-left corner, click New â†’ Collection . Enter collection name as API Training and click Create . This collection will store all your API requests and simulate a real project structure. ðŸ”¹ STEP 22 â€” Fetch Real User Data from API (Dynamic Test Data) Inside the collection, click Add Request and name it Get User Data . Set: Method â†’ GET URL â†’ https://dummyjson.com/users/1 Click Send . You will get a full user response. From this response, identify: username password Example: "username": "emilys", "password": "emilyspass" ðŸ‘‰ This step ensures you are using real API data instead of hardcoded values ðŸ”¹ STEP 23 â€” Extract Username and Password Automatically Go to the Tests tab of the same request. Paste: let res = pm.response.json(); pm.environment.set("username", res.username); pm.environment.set("password", res.password); Now create an Environment (top-right â†’ Environments â†’ New): Variable Value username (empty) password (empty) token (empty) Save and select this environment. Click Send again â†’ values will be stored automatically. ðŸ”¹ STEP 24 â€” Perform Login using Extracted Credentials (AUTHENTICATION) Create a new request named Login API . Set: Method â†’ POST URL â†’ https://dummyjson.com/auth/login Go to Body â†’ raw â†’ JSON: { "username": "{{username}}", "password": "{{password}}" } Click Send . ðŸ‘‰ This step is AUTHENTICATION âœ” Server verifies identity âœ” If correct â†’ token generated ðŸ‘‰ Negative test (important): Change password â†’ expect 400 / Invalid credentials âœ” Means identity check failed ðŸ”¹ STEP 25 â€” Extract Authentication Token Go to Tests tab of Login API. Paste: let res = pm.response.json(); pm.environment.set("token", res.token); Click Send again . Now token is stored in environment variable. ðŸ‘‰ This token represents authenticated session ðŸ”¹ STEP 26 â€” Call Protected API using Token (AUTHORIZATION) Create new request â†’ name it Get Profile . Set: Method â†’ GET URL â†’ https://dummyjson.com/auth/me Go to Authorization tab: Type â†’ Bearer Token Token â†’ {{token}} Click Send ðŸ‘‰ This step is AUTHORIZATION âœ” Server checks token âœ” Allows access only if valid ðŸ”¹ STEP 27 â€” Validate Unauthorized Access (Negative Testing) In the same request: Remove token â†’ Click Send â†’ 401 Unauthorized Use wrong token â†’ Click Send â†’ 401 Unauthorized ðŸ‘‰ Key understanding: âœ” User exists âŒ But access denied ðŸ‘‰ This clearly shows Authorization failure (not Authentication) ðŸ”¹ STEP 28 â€” Understand API Endpoint Behavior Test different endpoints: https://dummyjson.com/users â†’ works without auth https://dummyjson.com/products â†’ works without auth https://dummyjson.com/auth/me â†’ requires token ðŸ‘‰ This shows real-world: âœ” Public APIs âœ” Protected APIs ðŸ”¹ STEP 29 â€” Automate API Chaining (End-to-End Flow) Now your flow is: Get user data â†’ Extract username/password â†’ Login (Authentication) â†’ Extract token â†’ Call protected API (Authorization) All values flow automatically using environment variables. ðŸ”¹ STEP 30 â€” Organize APIs into Collection Structure Create folders inside collection: User APIs Auth APIs Move requests accordingly to maintain clean structure. ðŸ”¹ STEP 31 â€” Use Base URL via Environment Add variable: Variable Value baseUrl https://dummyjson.com Update URLs: {{baseUrl}}/users/1 {{baseUrl}}/auth/login {{baseUrl}}/auth/me ðŸ”¹ STEP 32 â€” Add Pre-request Script (Dynamic Data Handling) In any request â†’ Pre-request Script: let random = Math.floor(Math.random() * 1000); pm.environment.set("dynamicUser", "user" + random); Used for dynamic testing scenarios. ðŸ”¹ STEP 33 â€” Add Validation using Test Scripts In Tests tab: pm.test("Status is 200", () => { pm.response.to.have.status(200); }); pm.test("Token exists", () => { let res = pm.response.json(); pm.expect(res.token).to.not.be.null; }); ðŸ”¹ STEP 34 â€” Run Complete Flow using Collection Runner Click collection â†’ Click Run Select all requests â†’ Click Run Collection This executes full flow sequentially. Got it â€” now crystal clear. You want Google Doc style format : ðŸ‘‰ Only step title as header (bold H2) ðŸ‘‰ Everything else = normal paragraph text (no extra headings) ðŸ‘‰ Detailed + practical Letâ€™s do it properly ðŸ‘‡ ðŸ”¹ STEP 35 â€” Data Driven Testing (Using CSV in Postman Runner) Open Postman and make sure your collection already has a working Login API that uses {{username}} and {{password}} . Now create a CSV file using Excel or Notepad and save it as testdata.csv . Inside that file, write: username,password emilys,emilyspass kminchelle,0lelplR Now go back to Postman and click on your collection name in the left panel. On the top right of the collection, click the Run (â–¶) button. This opens the Collection Runner window. On the right side, you will see an option called â€œSelect Fileâ€ under the Data section. Click it and upload your CSV file. Ensure your request body in Postman is written like: { "username": "{{username}}", "password": "{{password}}" } Now click Run Collection . Postman will execute the same API multiple times, once for each row in the CSV. You can click each iteration to see different responses. If one row has invalid credentials, it will fail â€” this automatically gives you both positive and negative testing in one run. This step is extremely important because it removes hardcoding and allows scalable test execution. ðŸ”¹ STEP 36 â€” Execute via Newman (CLI Automation) Now you move from UI testing to automation execution. In Postman, click on your collection â†’ click the three dots (â‹®) â†’ click Export â†’ select Collection v2.1 â†’ save the JSON file. Do the same for your Environment file. Now install Newman using terminal: npm install -g newman Open Command Prompt or PowerShell and navigate to the folder where your files are saved. Run: newman run collection.json -e environment.json You will see execution logs directly in terminal â€” each API call, status code, and result. You can also generate reports: newman run collection.json -e environment.json -r html This creates a detailed HTML report. This step is important because it allows you to run API tests without Postman UI, which is exactly how execution happens in real projects. ðŸ”¹ STEP 37 â€” CI/CD Integration (Jenkins & GitHub Actions) Now take your Newman command and integrate it into CI/CD tools. In Jenkins, create a new job and go to the Build section. Choose Execute Windows Batch Command and paste: newman run collection.json -e environment.json Click Build Now , and Jenkins will execute your API tests automatically. For GitHub Actions, create a file .github/workflows/api.yml and add: name: API Tests on: [push] jobs: test: runs-on: ubuntu-latest steps: - name: Run Newman run: npx newman run collection.json -e environment.json Now whenever code is pushed, your API tests will run automatically. This is real-world automation where testing is part of the development pipeline. It ensures bugs are caught early without manual effort. ðŸ”¹ STEP 38 â€” AI for Test Script Generation (Postman Tests Tab) Instead of writing test scripts manually, you can use AI tools like ChatGPT or Cursor AI. For example, you can give a prompt: â€œGenerate Postman test script for login API with status validation and token checkâ€ AI will generate something like: pm.test("Status is 200", function () { pm.response.to.have.status(200); }); pm.test("Token exists", function () { let res = pm.response.json(); pm.expect(res.token).to.not.be.null; }); Now go to Postman â†’ open your request â†’ click Tests tab â†’ paste this script â†’ click Send. You will see test results in the bottom panel. This speeds up your work, but remember AI gives generic output â€” you must enhance it with real business validations. ðŸ”¹ STEP 39 â€” Contract Testing using JSON Schema Validation Go to your Login API â†’ open Tests tab . Define a schema: const schema = { type: "object", properties: { id: { type: "number" }, username: { type: "string" }, token: { type: "string" } }, required: ["id", "username"] }; Now validate response: pm.test("Schema is valid", function () { pm.response.to.have.jsonSchema(schema); }); Click Send. If API response structure changes, this test will fail immediately. This is very important in real projects because frontend depends on response structure. Even if API works, wrong structure can break UI â€” this step catches that early. ðŸ”¹ STEP 40 â€” End-to-End API Testing Flow (Authentication â†’ Authorization) Now combine everything into one real workflow. Your flow is: GET /users/1 â†’ extract username and password POST /auth/login â†’ authenticate user GET /auth/me â†’ access protected API In first request, extract: let res = pm.response.json(); pm.environment.set("username", res.username); pm.environment.set("password", res.password); In second request, use: { "username": "{{username}}", "password": "{{password}}" } Extract token: pm.environment.set("token", res.token); In third request, go to Authorization tab â†’ select Bearer Token â†’ enter {{token}} . Click Send and verify response. Now test negative: Change password â†’ login fails Remove token â†’ 401 Unauthorized Use wrong token â†’ access denied This is not just testing APIs individually â€” this is testing complete system flow, which is how real backend validation works in production systems. If you want, next I can: ðŸ‘‰ Convert this entire flow into RestAssured Java automation (your domain) ðŸ‘‰ Or give interview questions from these steps Just say: â€œautomation nextâ€ â€“ Step 41 API+UI INTEGRATION # ðŸš€ PHASE 0 â€” CLEAN START (MANDATORY) ## ðŸ”¹ STEP 0.1 â€” Close all ports ```bash netstat -ano | findstr :3000 ``` Kill: ```bash taskkill /PID /F ``` ðŸ‘‰ Do same for 4000 if needed --- # ðŸš€ PHASE 1 â€” PROJECT SETUP ## ðŸ”¹ STEP 1.1 â€” Create project ```bash mkdir shopping-app cd shopping-app npm init -y ``` --- ## ðŸ”¹ STEP 1.2 â€” Install dependencies ```bash npm install express jsonwebtoken cors ``` --- # ðŸš€ PHASE 2 â€” BACKEND (SERVER) ## ðŸ”¹ STEP 2.1 â€” Create `server.js` ðŸ‘‰ Create file: `server.js` ðŸ‘‰ Paste FULL code: ```javascript const express = require("express"); const jwt = require("jsonwebtoken"); const cors = require("cors"); const app = express(); app.use(cors()); app.use(express.json()); const SECRET = "mysecret"; // ðŸ”¹ DATA let users = [ { id: 1, username: "wasim", password: "1234" } ]; let products = [ { id: 1, name: "Laptop", price: 50000 }, { id: 2, name: "iPhone", price: 80000 } ]; let cart = []; // ðŸ”¹ TEST app.get("/", (req, res) => { res.send("API WORKING âœ…"); }); // ðŸ”¹ LOGIN app.post("/login", (req, res) => { const { username, password } = req.body; let user = users.find(u => u.username === username && u.password === password); if (!user) return res.status(401).json({ message: "Invalid credentials" }); let token = jwt.sign({ username }, SECRET, { expiresIn: "1h" }); res.json({ token }); }); // ðŸ”¹ AUTH function authenticate(req, res, next) { let authHeader = req.headers["authorization"]; if (!authHeader) return res.status(401).json({ message: "No token" }); let token = authHeader.split(" ")[1]; try { jwt.verify(token, SECRET); next(); } catch { return res.status(403).json({ message: "Invalid token" }); } } // ðŸ”¹ PRODUCTS app.get("/products", (req, res) => { res.json(products); }); // ðŸ”¹ CART app.get("/cart", authenticate, (req, res) => { res.json(cart); }); app.post("/cart", authenticate, (req, res) => { cart.push({ id: Date.now(), ...req.body }); res.json({ message: "Added" }); }); app.delete("/cart/:id", authenticate, (req, res) => { cart = cart.filter(c => c.id != req.params.id); res.json({ message: "Deleted" }); }); // ðŸ”¹ START app.listen(4000, () => console.log("Server running on port 4000")); ``` --- ## ðŸ”¹ STEP 2.2 â€” Run server ```bash node server.js ``` --- ## ðŸ”¹ STEP 2.3 â€” Verify Open: ``` http://localhost:4000/ ``` ðŸ‘‰ Output: ``` API WORKING âœ… ``` --- # ðŸš€ PHASE 3 â€” POSTMAN TESTING --- ## ðŸ”¹ STEP 3.1 â€” LOGIN POST ``` http://localhost:4000/login ``` Body â†’ raw â†’ JSON: ```json { "username": "wasim", "password": "1234" } ``` ðŸ‘‰ Copy token --- ## ðŸ”¹ STEP 3.2 â€” GET PRODUCTS GET ``` http://localhost:3000/products ``` --- ## ðŸ”¹ STEP 3.3 â€” ADD TO CART POST ``` http://localhost:3000/cart ``` Headers: ``` Authorization: Bearer Content-Type: application/json ``` Body: ```json { "productId": 1, "name": "Laptop", "price": 50000, "quantity": 1 } ``` --- ## ðŸ”¹ STEP 3.4 â€” GET CART GET ``` http://localhost:4000/cart ``` Header: ``` Authorization: Bearer ``` --- ## ðŸ”¹ STEP 3.5 â€” NEGATIVE TEST ðŸ‘‰ Remove token â†’ Send ðŸ‘‰ Expected: ``` 401 Unauthorized ``` API Auth Required Why /products âŒ No Public data /login âŒ No Entry point /cart âœ… Yes User-specific /orders (future) âœ… Yes Sensitive --- # ðŸš€ PHASE 4 â€” FRONTEND --- ## ðŸ”¹ STEP 4.1 â€” Create `index.html` ðŸ‘‰ Create file in same folder ðŸ‘‰ Paste FULL: ```html Shopping App

ðŸ›’ Shopping App

Products

Cart

``` --- ## ðŸ”¹ STEP 4.2 â€” Run UI ðŸ‘‰ Double click `index.html` --- # ðŸ”¥ FINAL FLOW ``` Login â†’ token â†“ UI stores token â†“ Token sent in header â†“ Backend validates â†“ Cart allowed ```